Names of software processes executing under UNIX environments are not necessarily unique. For example, all Java programs have a process name of “install_path java.” UNIX environments assign a unique process ID to each active process and require this process ID as a parameter on external requests to manage a specific process. Therefore, external automation products like, for example, Tivoli System Automation for z/OS, are required to first lookup and identify the correct process ID, in the process table, before requests can be sent to monitor and automate that process. Automation products unsuccessfully attempt to identify processes by name, because automation products do not have a way to resolve which unique process ID to select from a potentially long list of identically named processes. Some automation products simply select the first process found with the matching name. Therefore, today, only processes with unique process names can reliably be monitored out-of-the-box by automation products.
Software processes executing under UNIX environments are managed in a hierarchical tree structure containing links to the parent process. There is a root process which has a process ID of 1. Each process may create as many child processes as needed. Each child process in turn is assigned its own unique process ID. The UNIX environment keeps the process name, command line parameters, process attributes, and a backward pointer to the parent process, for each active process in a process table. While process names may not be unique, consideration of the command line parameters of that process or the attributes of the parent process may be useful in differentiating between similarly named processes.
Additionally, it is becoming more common for large computer systems, such as mainframes, to support a UNIX environment as far as automation is concerned. For example, within IBM's z/OS, there is a UNIX environment called UNIX System Services (USS), capable of running multiple UNIX processes. USS is a complete UNIX kernel that runs in parallel to and is tightly integrated with the traditional mainframe base control program (BCP). Operators of these large computer systems wish to monitor and automate UNIX applications in the same way as they automate their existing legacy jobs, from the same operator's console and without the need for special skills. A UNIX application in this context is a program which in turn is a sequence of coded instructions. When this program is started, an environment has to be created for it consisting of a program counter, storage, and other mechanisms an operating system needs to control proper execution of that program. This environment is called a process. Each process has a unique ID while the program name may be ambiguous. As used herein, the term “process name” means the name of the program and the path within the UNIX filesystem, where the program is located that is currently executing within this process.
One current method used to identify similarly named processes is to create symbolic unique links. However, the creation of these links is a manual activity and requires both setup to the application itself and the adding of plain automation rules to the automation product. The complexity of the automation environment and the manual effort for managing this environment grows with the number of symbolic links.
A second method used to identify similarly named processes is to create a wrapper script with a unique name. However, with this approach, the automation product would only be able to monitor the script process and not the actual process started by the script.
What is needed in the art is a way to allow an automation product to automate not only on the basis of process name, but also based on the start parameters sent to the process and by the method the process was invoked.